\chapter{Transcription of Interview with Dirk Trossen}
\label{app:dirktrossen}
I: Interviewer \\
\noindent D: Dirk Trossen \bigskip

\noindent (01:20) \textbf{\textit{I}: Can you please give a brief introduction of yourself and your work?} (01:30) \textit{D}: Well with respect to that particular piece, I did that work at a University of Cambridge for about three years. I'm no longer with University of Cambridge though. I'm currently in the UK. But for the sake of the question that I just assume we talk about [...] April this year. Before I joined Cambridge I used to work for BT (British Telecom). We started the research in the UK and I joined Cambridge in 2010 and in the end that was the end of the first project of known PURSUIT continued, oh sorry started in 2010 until February of this year 2013. \bigskip

\noindent (02:25) \textbf{\textit{I}: Can you please tell us also a little bit about the relation of this EU FP7 project and PURSUIT. What was the relation between this EU FP7 and PURSUIT?} (02:45) \textit{D}: Well, PURSUIT is an FP7 Project, the framework programme started in 2008, we had a first project called PSIRP, which was the first project in Information Centric Networking, then it continued in 2010 as the PURSUIT project both of them were FP7 project. \bigskip

\noindent (03.15) \textbf{\textit{I}: Can you please elaborate the role of PURSUIT and how it influenced the development of the Internet in this particular area of Information-Centric Networking?} (03:30) \textit{D}: The first project, because PURSUIT was a continuation project, was the one out of two first efforts in the EU that has been funded in the area of Information Centric Networking. In 2008 they worked as an answer to the work started at the same time in the U.S. The EU decided to fund two efforts in the EU and PSIRP was one of them, and PURSUIT continued in the efforts in 2010. So it's one of the earliest and also longest running projects in that area if you count both of them together. So if I interchange we talk about PURSUIT as I said it goes, if you go back to 2008 it wasn't called PURSUIT that time but they are essentially the same efforts if you count them over five years. \bigskip

\noindent (04:30) \textbf{\textit{I}: Ok, so what do you think are the main drivers towards an Information Centric Network Architecture?} (04:45) \textit{D}: Well it's a good question you can say there is usually a quick answer but you're not gonna get that from me. At least when we started there wasn't an obvious answer. It was not about making content distribution more efficient because CDNs are doing descent job in making that happen. The reason we started in 2008 was: if you think about disseminating information then the usage of computation and storage, which is what you do in CDNs, is very inefficiently supported only. And a way to make CDNs work is all about a way of intersecting HTTP level calls, do IP packet inspection, all of that leads to a significant inefficiency. So when we started, we recognized that if you take computation[5:50], storage and communication as three parameters of solving a problem, there is potentially a better way of doing it than the current way the Internet does it. So it was really was driven by efficiency and improved scalability as well as also new applications - not necessarily making the current applications better. \bigskip

\noindent (06:15) \textbf{\textit{I}: There have been a lot of approaches to this ICN Networking and have you done any research into how to actually deploy ICNs into the society.} (06:35) \textit{D}: Yes we did actually very early. The first part, the PSIRP part, had a migration and deployment study. And that was largely driven because at that time I was part of BT, and BT as an operator is obviously very interested in how can you deploy the technology. Having a very blunt answer and saying: ``throw away the old boxes and deploy these new fancy boxes'' is not a very good answer. So therefore BT was very interested on how you migrate. But it is naturally difficult, because the Internet wasn't deployed natively either. In 2013, this year actually, BT switched off the last dial ups. Most people don't remember dial-up any more but dial-up was essentially an overlay of the Internet on top of the telephony system. And we ... a very similar migration strategy. Our testbeds that we are having, runs over the standard Internet, so it runs as an overlay. We obviously also have high performance testbeds, which runs straight on top of Ethernet, so there is no really IP anymore. But there's nothing that prevents you - IP is a perfect link layer. There's nothing wrong you know with overlaying it. I think what's more interesting is: how do you migrate from a business model perspective? And we did studies around it. We know the impact of content dissemination changing over time. And again there are different strategies how to make that work so that the ones, who ultimately want this out, are still willing to change. So we have done quite a bit of socio economic works in the project. \bigskip

\noindent (08:28) \textbf{\textit{I}: Did you write any papers about this issue of migrating into the ICN infrastructure? It has been very difficult for us to find anything.} (08:38) \textit{D}: To begin to write about my question itself largely because it was a very, very big topic, and we were really relatively too lazy to shrink it down to 6 pages or 8 pages, you know, that is the usual conference size that was partially the problem because it is a very significant area, and shrinking it down to some blunt messages it does not do the work justice. What we have done, though, both the projects - PSIRP and PURSUIT - were very open, all of the deliverables were open. It was not entirely true for PSIRP. PSIRP actually had two deliverables that were not open. It were restricted and you would not be able to see them. One of them was the migration. We made that the deliverable open after we finished it. So you should be able to on the PSIRP side, which is psirp.org, there is the deliverable available on migration. The reason that it was so difficult was that we developed Models that we developed systems that can make models you can put into a benzin simulator and simulate, really, and it is quite a bit of material but it is also quite a bit to read. \bigskip

\noindent (09:58) \textbf{\textit{I}: If we should, then, ask you a simple question, I know now we are now going into a very complicated area, a very big area, we can ask you what you think are the main barriers regarding the deployment of ICN?} (10:22) \textit{D}: It is largely change, economic change as well as equipment change - and that is not a surprising answer, because you know any new proposition has the same obstacles. It is not a big fundamental reason, because a lot of the actual - if you go beyond this... Change is always a difficult thing. There are certain technical issues on top of other technical issues. People at the beginning particularly at the end of the first project, were very concerned about backwards compatibility: we have all this installed bases of application - Can we run them on top of an information thing? - would we have to re-write? - and of course you don't. We were very early in the project and we had no better version of it. We had a socket abstraction layer of it saying: it looks like you have an IP network underneath, so you can run everything on top of IP including the control protocols DHCP or ICP - you can run them on top of an ICN network and therefore backwards compatibility is there. So that argument went out the window very quickly. The installed bases, as I said, you can migrate on top of it, but change always goes beyond these nitty-gritty details of how you actually make it work. That is relatively easy to show - it has to do with the economic change and it has to do with who needs to do the first step, which was part of the study that we had done in the first project. So who were the industries that were potentially more likely to adopt the technology? It does not go after the ``what is well known'' like IP, it just goes straight for something new. Which is also a psychological issue. And that is certainly a barrier to the adoption of any new technology. The other thing that we also identified, is who are the market players taking it up? Maybe one could think of equipment vendors, but on the other hand equipment vendors make a lot of money selling today's infrastructure, and therefore there is no directly very clear route to take equipment vendors to convince them to invest in new equipment to be manufactured and sold that is not a very straight forward route. Or in a simpler question - if you think about the change from Telephony to IP: who is the new Cisco? It is not going to be Cisco because Cisco is an incumbent now. We have not identified any one because we don't see any company at the horizon that says ``we are taking this area, push it forward and disrupt the Cisco of today'' the same way Cisco disrupted Lucent 20-25 years ago. So there are more things that you realize very quickly, when you do a project like this. It has increasingly little to do with the actual technology, the architecture. \bigskip

\noindent (13:37) \textbf{\textit{I}: As far as I could hear your PURSUIT has some advantages over other ICN implementations or am I wrong? Who has these advantages on top building IP - was it PURSUIT?} (14:01) \textit{D}: They are all parsable in a way. Still there are differences in how much renewal all of the different projects do. We can run on top of existing infrastructures, CCN can and very similar: if you want to utilize the full potential you obviously have to deploy more of the native one and less of the overlay one. But that is in itself not necessarily an advantage or disadvantage, because you might be in an environment for instance if you aim for a smart city deployment and the fact that you have to run more of a new infrastructure to utilize the benefits might not be an issue because a lot of cities do not have an infrastructure in any case and therefore they would go for a new deployment anyway. So that isn't necessarily so it is more about what we try to emphasize more, was what are some of the architectural benefits compared to some of the other road roaches? So we put in particular in the PURSUIT efforts the second half of the research more emphasis on the architecture. And what does it mean - the architectural differences with respect to not only performance but also functional possibilities that you can have. \bigskip

\noindent (15:27) \textbf{\textit{I}: So did you in any way collaborate with other ICN research projects? Did you share information? Get information?} (15:34) \textit{D}: Yes, at the same time as we did our efforts the community also grew. First of all there were other projects that received funding and we collaborate with them and with PURSUIT we had common workshops, but some of the newer projects that were funded, they approached us and said: ``well would you like to do something?'' and we organized workshops, exchanged how we do things. That is quite common at the same projects generally FP7 projects are encouraged and sometimes are forced to do it, because obviously they are supposed to talk to each other. And be natural with this. Also we were part of the ICN activities in workshops where we were either in the TBC or the steering crew, people from the project. There have been three different ICN workshops in SIGCOMM, which was abnormity for SIGCOMM usually only allows two workshops. The third workshop has to be spun out of the conference. But there were 3 ICN workshops in SIGCOMM and we were on the steering crew there. And on the TBC quite a few people from the project were on the TBC, which is a more academic form of collaboration. Because the papers that are naturally in the workshop and come from all over the place, they are not only from the PURSUIT project, some people use the PURSUIT technologies others use CCN technologies. We have an interchange and can see what is happening. \bigskip

\noindent (17:09) \textbf{\textit{I}: You seem very optimistic about ICN compared to other people so if you think of the future of the Internet you also inherently think about ICN?} (17:27) \textit{D}: It depends a bit. There is obviously the optimal route, but realistically, that it is not possible for you can't really change infrastructure easily. So it is along the academic route rather than the optimal one. So you would just think of how it would be if you had a new architecture. That is certainly the question we ask. But it does not mean that if you come to the conclusion that just change the architecture. It is very difficult that the research has the benefits - it has of lot of benefits - a lot of the designed insights, the different ICN projects, not only PURSUIT, achieve, can be used in the design of solutions, be in the current 5G effort or in network virtualization. There are lots of ideas I think that have been studied in the ICN space that are very beneficial to this new outlets as well. So that even though you look at it in like 5 or 10 years down and it is not really an ICN architecture as it was envisioned, the will, which was always the inherent idea of performing this type of research. They are ideas that come from this area and will driven forward with the idea of getting ICN to work. They still find entry into other areas, and they are very optimistic of that really. \bigskip

\noindent (19:03) \textbf{\textit{I}: Actually I have one last question about that was just what I'm thinking about how will ever compete with the existing, perfectly, very well working CDNs but I think you already meant answer that question, so I don't know if you have anything else to add about that.} (19:25) \textit{D}: When it comes to ... there are very easy scenarios that we also created where you will not only stretch but most certainly have CDNs fail compared to the efficiently that you can achieve from the ICN. It's not that difficult to achieve this or to create those scenarios. It sometimes more of a problem that occurrence on a very particular design target, they are very much focus on a very particular usage, but what operators that are commissioning CDNs have in mind, and therefore maybe some of the scenarios that we have in mind, are not in the direct objective of the deployment. They can be scenarios that include much more mobility, scenarios that include larger degree of multicast, which is actually a typical one that would have a CDN explode. Just imagine that you are in an area where you have high traffic delivered at the same time - CDN, because it works on the HTTP level, would play out content, even if the content happen to be in the CDN several times. It doesn't happen in an ICN. It would use the native multicast; the load could be significantly lower on the CDN itself on the server as well as on the network where it's delivered. And so we've created those scenarios where we said: it is even in that the relatively boring level of content dissemination where you can easily show that in a similar deployment scenario, an ICN significantly outperformed a CDN based one. \bigskip


\noindent (21:07) \textbf{\textit{I}: Thank you very much for that and I don't have more questions for my paper here. Is it ok if some of the other guys have some questions?} \textit{D}: Sure. \bigskip

\noindent (21:35) \textbf{\textit{I}: There are different approaches of ICN architecture. What will happen in the future - will these approaches gather, or use one of the approaches?} (22:10) \textit{D}: It is not unnatural, and probably not undesirable, that you have different approaches to the same idea. There wasn't the single IP either. Actually, the IP was one of the later candidates in the current Internet. And it was actually, at the time it came out, one of the least desirable ones. Even in hindsight, you still find people say it was probably also the worst choice. I just saw a presentation two days ago where the presenter very explicitly was making the point that the IP of that time of the decision was political choice and it was not the technically best choice.  So, it is not unnatural that you have such one, if the general idea - the information of trustability etc. there are different ways of doing it, that's certainly not an issue. Like in any consolidation, it is hard to find good reasons for consolidation. I mentioned there could be reasons to have to do with political battles. Somebody says it is better, because you have more support for it, and there it is not necessary a technical reason. It can be reasons for deployment: if one approach, even if it is not necessarily the better one, gains larger deployment - unfortunately, that is more likely to win the battle. We have tried to put some emphasis on trying to understand, and as such more rationalize, what are the differences? where do the differences actually matter? where do they not matter? - There are differences that actually do not matter much. There are sometimes also differences that seem to be differences, but if you look closely, there actually are not any differences. You might get confused: you think that on the face it looks different, but you look at the architectures, there are no difference at all. I believe we do this too little, but as I have already said that has also been very little done in the IP aspect. Nobody really was taught ... attached to locate ... IP, CRP, and a few people understood the differences, but nobody was listening to them. As I said, when it was in the end decided, it was by making decision someone understands what it was for. It is a very typically way of doing it, unfortunately. \bigskip

\noindent (24:44) \textbf{\textit{I}: Which specific equipment need to be modified or chan{\-}ged?} \textit{D}: It depends on what your idea of deployment is. That was a very simply answer. If you want to go for native deployment, that means that you will have optimized forward into that work, that means that you have to replace the equivalent of today's routers. If that is not your deployment, then you just overlay - there is no change in the network, and everything happens to be been done by highly powerful engineers. This is what we do today. Our international test network is an overlay network on behalf of rather powerful server machines that are in our ICN forward - they are not in our network - they are the edge of the network. So the modifications are actually little to none. \bigskip

\noindent (26:00) \textbf{\textit{I}: In which particular areas where ICN has advantaged compared to CND and P2P, for example regarding cloud computing?} \textit{D}: Regarding P2P, it seems to be very straightforward comparison. But there are obviously significant differences, because ICN is pushing these ideas into network, at least architecturally, whether or not you will implement it in the network. As it said before, it depends on the deployment. But there are significant differences in that architecturally the network is aware of information-centric destinations, it is aware of the actual graphs that are within the different network elements. That just not the case with P2P. P2P is indeed entirely on the top of IP, therefore it has less possibilities in terms of optimizations. Cloud computing is a difficult one because cloud computing means a lot and nothing, really. In a way, if you think cloud computing is a combination of communication and computation - that is computation that can easily migrate. This is exactly what we are trying to do as well. It is a little long discussion to argue why I believe that ICN is a better approach of doing it. It has to do with the fact that it has underlying network that is information aware, which the current cloud computing doesn't have. Current cloud computing has a nature that is not information aware. Therefore optimizing the communication is harder. It is not impossible, but it is harder. Therefore it has more effort to do it. If you want to come to similar point of operation, you will always spend more energy in a could computing scenario today than if you would run it on the top of the ICN.

